True Separate Compilation for SML]

In current days, separate compilation plays a very important role in the practical program development. As the name “separate compilation” indicates, it allows that the program is split into several source files. Each of them is self-contained in the sense it describes the import signature which are assumed to be provided by other code fragment and its own export declarations. Each unit can be compiled independently and then linked together as a whole. [1] proposes such an simple but elegant framework to describe the semantics of separate compilation and linking. Given a code fragment with the explicit import interface called linkset, it is compiled to a self-contained entity called intra-checking and then compatible modules can be safely linked together called inter-checking. As for the SML language, many SML compilers support the so-called incremental recompilation system such as the SML/NJ [2] and MLKit[3]. In these compiler systems, the compilation of the source files must be compiled incrementally. The interface of each source file is inferred automatically by the compiler without the interference of programmer. But a weak point of such strategy is that compiler always needs to know the implementation which imposes a really inconvenient situation in practical development. Imagine the following scenario: A and B cooperates to develop a software system and B depends on A. Without the implementation of A, B cannot do any real development. This is a serious obstacle to apply SML language into large scale software development. The ML dialect, Ocaml proposes a solution for cut-off separate compilation[4]. In Objective Caml, compilation units are regarded as a basic unit to be independently compiled and linked later. And each can be seen as special cases of structures and signatures, and the relationship between the units can be explained easily in terms of the ML module system. We use the example given in [4] to illustrate. A compilation unit A comprises two files: implementation file A.ml, consisting a sequence of definitions, analogous to the inside of a struct . . . end construct; interface file A.mli, which contains a sequence of specifications, analogous to the inside of a sig . . . end construct. Both files define a structure named A as if the following definition was entered at top-level as follows: